SuperHack/SuperHack CD.bin/Hack/MISC/BIGLAN_F.ZIP/BIGLAN_F.TXT

Text File | 1995-10-31 | 83.8 KB | 1,817 lines

BIG-LAN Frequently Asked Questions

Last Updated: July 24, 1995

Acknowledgements: A lot of people provided information for me and I
freely admit that I have not recorded the list of names.  Thanks
to all.

Contents
--------
I. About BIG-LAN
II. Explanation of this Memo
III. Sources of Information on Campus Networks
  1. Must-Read Sources
  2. A Few General Sources
  3. LISTSERV Mailing Lists
  4. Internet Mailing Lists
  5. Internet Mailing Lists with automatic subscription
  6. USENET/Netnews Groups
  7. Anonymous FTP-based Archive Sites
  8. LISTSERV-based Archive Sites
  9. RFCs (Internet "Request For Comments")
  10. Other Useful Online Papers
  11. Sources of Protocol Documents
  12. Useful Free Software
  13. Books
  14. Periodicals
  15. Training Courses
  16. Conferences
IV. Basic Glossary on Campus Networks
V. Frequently Asked Questions on Campus Networks
  1. What is the difference between Ethernet and IEEE 802.3?
  2. What is encapsulation?  What do I have to know about it?
  3. How do I know whether to use a router or a bridge?
  4. How do I know whether to use a bridge or a repeater?  How many
     repeaters may I put on an Ethernet?
  5. Should I use "manageable" hubs, concentrators, etc on my LAN?
  6. Which LAN technology should I use?  Arcnet?  FDDI?  Token Ring?
     10BASE-T?
  7. What is the ideal cable to install in a new building?
  8. What is the ideal cable to install between buildings on a campus?
  9. Whose routers are recommended?
  10. Whose bridges are recommended?
  11. Whose Ethernet equipment are recommended?
  12. Whose Token Ring equipment are recommended?
  13. Whose FDDI equipment are recommended?
  14. What PC network software is recommended?
  15. What protocols should run on a campus-wide LAN?
  16. What software is recommended for managing a campus-wide LAN?
  17. What terminal server is recommended?
  18. Whose troubleshooting equipment are recommended?
  19. What security products should I buy?
  20. Should the names of devices on my campus LAN have subdomains?
  21. Should client stations use POP?  Should they use just SMTP?
      Should I use some non-TCP/IP protocol for mail to/from client
      stations?
  22. Should I enable SQE/heartbeat?
  23. If I have a thinwire network interface card, how do I connect it
      to a 10BASE-T concentrator?
  24. How much does a collision slow down an Ethernet packet?
  25. Should I worry about Ethernet tailgating?

I. About BIG-LAN

   BIG-LAN is a mailing list for discussion of issues in designing and
   operating Campus-Size Local Area Networks, especially complex
   nes utilizing multiple technologies and supporting multiple
   protocols.  Topics include repeaters, bridges, routers and
   gateways; how to incorporate smaller Personal-Computer type LANs
   into the campus-wide LAN; how to unify the mail systems, etc.
   This is an ideal list in which to debate the relative merits of
   bridges vs routers.

   All requests to be added to or deleted from this list, problems,
   questions, etc., should be sent to [e-mail].
   Those familiar with LISTSERV can subscribe with
   [e-mail].

   Archives are available through [e-mail] and
   ftp://syr.edu/information/archives/big-lan/

   Coordinator: John Wobus <[e-mail]>

II. Explanation of this Memo

     Since BIG-LAN is not specific to any protocol family, it will
     not cover any particular protocol family in detail, e.g.  this
     is not a TCP/IP/Internet FAQ Memo.  Fortunately, there are some
     good TCP/IP FAQ Memos which are listed in the sources of
     information below.

     Suggestions, corrections, and contributions welcome.  Please
     send them to:

                [e-mail]

     An up-to-date copy of this memo may be retrieved via URL:

          http://web.syr.edu/~jmwobus/comfaqs/big-lan.faq

III. Sources of Information on Campus Networks

     This list favors "network" sources of information: available on
     the Internet and/or BITNET and other similar networks; if you
     have access to BIG-LAN then you have access to one of these
     networks; and these sources are not the kind which you can
     discover through vendors, books, bookstores, or libraries.

  1. Must-Read Sources

      These are documents that you definitely should get and read if you
      have questions about Campus Networks.

    a. Charles Spurgeon's reading list (see below under "Other Useful
        Online Papers").
    b. RFCs 1175, 1594, 1207, and 1392 (see below under "RFCs").

  2. A Few General Sources

     These are network resources & mechanisms for getting all kinds
     of information--not just on Networking; thus we can't cover them
     very thoroughly in this memo.

    a. LISTSERV - mailing list servers & file servers on BITNET,
        accessible via e-mail.  Can be reached and used from a lot of
        networks.  Mail the command INFO to any LISTSERV for help.
        Also have database commands (i.e. search commands) for archives
        they store.
    b. Usenet News/Netnews: distributed bulletin board with discussions
        on lots of topics.  Distributed through the Internet and through
        UUCP.
    c. Anonymous ftp: the main way to make files available on the
        Internet.  ftp to a site using username "anonymous".  A
        password is always demanded--sometimes a banner tells you what
        to use--otherwise "guest" almost always works.
    d. Archie servers - network-accessible databases of where to get
        files via anonymous ftp.  Access is through telnet, rlogin,
        mail, or a special "archie" protocol.  To use via telnet,
        enter username archie.  Some servers: archie.ans.net,
        archie.sura.net, archie.mcgill.edu, archie.unl.edu.
    e. WAIS - Internet-accessible databases on different topics.
        Available via WAIS protocol (basically Z39.50).  Client
        (and server) software is collected on quake.think.com as
        well as a WAIS database of WAIS servers.
    f. ftplist.txt - collected list of anonymous ftp sites.
        Stored lots of places in anonymous ftp including syr.edu.
    g. Internet gopher - something like anonymous ftp only more
        advanced:  to get started, I suggest ftping
        boombox.micro.umn.edu and getting information on gopher.  A
        number of sites have servers.
    h. Internet List of lists: available by anonymous ftp from
        ftp.nisc.sri.com, or through a mail-based file server
        at [e-mail].
    i. LISTSERV internal list of lists.  Available by mailing the
        command LIST GLOBAL to any LISTSERV.
    j. news.answers - newsgroup that distributes Frequently Asked
        Questions memos for lots of Netnews groups.
    k. FAQ archive available via anonymous ftp on rtfm.mit.edu
        From the archives of news.answers, Frequently Asked Question
        memos for lots of Netnews groups.
    l. news.announce.newusers - has periodic postings about how to
        use Usenet/Netnews and also a lot about mailing lists.
    m. BITFTP.  A BITNET server that allows BITNET sites to use the
        Internet's File Transfer Protocol to send/receive files to
        ftpable Internet sites.  For more information, send mail
        to BITFTP@PUCC with HELP as the message body.
    n. Database of lists managed by [e-mail].  Use through
        LISTSERV's database interface.
    o. Maas files--Indexes & abstracts about various services available
        via Internet & BITNET including some related to campus networks.
        Available via anonymous ftp from ftp.unt.edu.
    p. [e-mail] mailing list.  A list to exchange
        information on the location of network resources.
        LISTSERV-based so use instructions below to subscribe, etc.
    q. World Wide Web servers.  You need WWW or Mosaic software to
        access them.  A good server to start with is www.ncsa.uiuc.edu.
        Mosaic is available from ftp.ncsa.uiuc.edu.


  3. LISTSERV Mailing Lists

      Send a "SUBSCRIBE" command to LISTSERV@foo, e.g.
              SUBSCRIBE BIG-LAN John Doe

    a. [e-mail]
    b. [e-mail]
    c. [e-mail]/IDBSU.IDBSU.EDU
    d. [e-mail]
    e. [e-mail]    (Campus Wide E-mail)
    f. [e-mail]         (Campus Wide Information Systems)
    g. [e-mail]
    h. [e-mail]      (LANWatch User List)
    i. [e-mail]
    j. [e-mail]
    h. [e-mail]    (Help re networking software)
    i. [e-mail]      (LanWorks PCSA stuff)
    j. [e-mail]     (MS LAN MAN stuff)

  4. Internet Mailing Lists

      Send a subscription request for list foo to foo-request@blah

    a. [e-mail]             (gives you 2 ways)
    b. [e-mail]
    c. [e-mail]          (Proteon routers)
    d. [e-mail]
    e. [e-mail]
    f. [e-mail]
    g. [e-mail]
    h. [e-mail]
    i. [e-mail]
    j. [e-mail]               (OSPF IP routing protocol)
    k. [e-mail]
    l. [e-mail]
    m. [e-mail]
    n. [e-mail]       (Packet Drivers)
    o. [e-mail]         gatewayed to comp.dcom.cell-relay)

  5. Internet Mailing Lists with automatic subscription

     Send a "SUBSCRIBE" command to the listed server.

    a. [e-mail]          [e-mail]
                                          (about firewall routers)
    b. [e-mail]   [e-mail]
                                          (same list in digested form)

  6. USENET/Netnews Groups

    a. comp.dcom.*          lans.*, modems, sys.cisco, telecom, ...
    b. comp.protocols.*     appletalk, tcp-ip.*, ibm, ppp, ...
    c. comp.sys.proteon
    d. comp.sys.novell
    e. comp.sys.mac.comm
    f. bit.listserv.big-lan  (Note: these groups give Netnews
    g. bit.listserv.novell     readers a way to read the corresponding
    h. bit.listserv.cwis-l      LISTSERV lists)
    i. bit.listserv.cw-mail
    j. bit.listserv.3com-l
    k. alt.dcom.*           catv, telecom, ...

  7. Anonymous FTP-based Archive Sites

    a. syr.edu: BIG-LAN mailing list; NOVELL mailing list; a collection
        of network-oriented papers & faq memos.
    b. spot.colorado.edu: cisco mailing list & some other network stuff
    c. hsdndev.harvard.edu: (in ndtl/results) Results of Scott
        Bradner's router benchmarks.
    d. ftp.uu.net: a treasure trove of software.
    e. wuarchive.wustl.edu: a treasure trove of software.
    f. ftp.ftp.com: packet drivers, some Unix software, other stuff.
    g. ftp.utexas.edu: collection of networking info & software--
        a lot of good information about Ethernet.
    h. ftp.novell.com: files Novell makes available.  Mirrored at
        netlab2.usu.edu, bnug.proteon.com, ftp.rg.nl, tui.lincoln.ac.nz.
    i. ftp.cisco.com: files Cisco makes available & some interesting
        applications.
    j. gatekeeper.dec.com: a treasure trove of software & stuff
        (the stuff that was on decwrl.dec.com).
    k. lux.levels.unisa.edu.au: files that 3Com distributes via
        Compuserve.
    l. ftp.unt.edu: Maas files and other goodies.
    m. oak.oakland.edu: "the simtel collection, formerly at
        simtel20.army.mil"; a treasure trove of software, including
        packet drivers (pd1:<msdos.pktdrvr>).  Mirrored on ftp.uu.net
        and wuarchive.wustl.edu.
    n. osi.ncsl.nist.gov: online copies of GOSIP & related documents.

  8. LISTSERV-based Archive Sites

     The brave can mail the command "INFO FILES" and/or the command
     "INFO DATABASE" to the LISTSERV for instructions.

    a. [e-mail]: BIG-LAN & NOVELL mailing list archives.

  9. RFCs (Internet "Request For Comments")

     Some anonymous ftp sites for RFCs: nic.ddn.mil, ftp.nisc.sri.com,
     nis.nsf.net, nisc.jvnc.net, venera.isi.edu, wuarchive.wustl.edu,
     ftp.salford.ac.uk.
     There are also some mail-based file servers:
     [e-mail], [e-mail], and
     [e-mail].

    a. RFC1470: FYI on a network management tool catalog: Tools for
        monitoring and debugging TCP/IP internets and interconnected
        devices
    b. RFC1175: FYI on where to start: A bibliography of
        internetworking information
    c. RFC1594: FYI on Questions and Answers: Answers to Commonly asked
        "New Internet User" Questions
    d. RFC1178: Choosing a name for your computer
    e. RFC1207: FYI on Questions and Answers: Answers to commonly
        asked "experienced Internet user" questions
    f. RFC1244: Site Security Handbook
    g. RFC1118: Hitchhiker's Guide to the Internet
    h. RFC1122 & RFC1123: Requirements for Internet Hosts
    i. RFC1208: A Glossary of Networking Terms
    j. RFC1180: A TCP/IP Tutorial
    k. RFC1173: Responsibilities of Host and Network Managers:  A
        Summary of the Oral Tradition of the Internet
    l. IAB Official Protocol Standards (Currently RFC1540 but it is
        periodically updated & given a new RFC number)
    m. Assigned Numbers (Currently RFC1340 but it is periodically
        updated & given a new RFC number; Includes field-values for
        protocols in the TCP/IP family as well as some others)
    n. RFC1392: Internet User's Glossary


  10. Other Useful Online Papers

    a. Charles Spurgeon. "Network Reading List: TCP/IP, UNIX, and
        Ethernet".  Available via anonymous ftp from ftp.utexas.edu
        in directory pub/netinfo/docs as net-read.txt and netread-ps.
        Also available via electronic-mail-based archive server.  Send
        the word "help" in the subject header or body of a message
        to [e-mail] for more information.
        Also available via www.
    b. Charles Hedrick. "Introduction to the Administration of an
        Internet-based Local Network".  Available via anonymous ftp
        from cs.rutgers.edu as runet/tcp-ip-admin.doc (also .ps).
    c. Charles Hedrick.  "Introduction to Internet Protocols."
        Available via anonymous ftp from cs.rutgers.edu as
        runet/tcp-ip-intro.doc (also .ps).
    d. Unofficial lists of codes used on 802.3 & Ethernet networks.
        Portions of the official list are not released, so various
        people compile unofficial lists.  One that is available via
        anonymous ftp is Michael Patton's pub/map/EtherNet-Codes
        on ftp.lcs.mit.edu.  See also RFC: "Assigned Numbers".
    e. Arthur Green: "Frequently Asked Questions for
        [e-mail] Mailing List."  Available via anonymous
        ftp from midir.ucd.ie.
    f. Brendan Kehoe: "Zen and the Art of the Internet: A Beginner's
        Guide to the Internet."  Available via anonymous ftp from
        ftp.cs.widener.edu in the pub/zen directory.
    g. ATM Bibliography.  Available via anonymous ftp from
        mythos.ucs.indiana.edu.
    h. John Wobus.  "Lan Mail Protocols".  Available via anonymous ftp
        from syr.edu under information/faqs/lan-mail-protocols
    i. John Wobus.  "Lan Technology".  Available via anonymous ftp from
        syr.edu under information/faqs/lan-technology
    j. Charles Spurgeon. "Guide to Ethernet".  Available via anonymous
        ftp from ftp.utexas.edu in pub/netinfo/ethernet as ethernet-guide.ps.
        See a above.
    k. Charles Spurgeon. "Guide to Ethernet Configuration".  Available via
        anonymous ftp from ftp.utexas.edu in pub/netinfo/ethernet as
        ethernet-config.ps.


  11. Sources of Protocol Documents

    a. Ethernet V2   DEC-Direct; 1-800-344-4825; DEC Part Number
                      AA-K759B-TK.

    b. IEEE 802      (802.3, Token Ring, 10BASE-T, etc) IEEE;
                      1-800-678-IEEE.
    c. TCP/IP        RFCs.  See RFCs (above).
    d. AppleTalk     APDA; 1-800-282-APDA.  Now a book in the
                      "Inside" series.
    e. OSI           Omnicom Inc.; 1-800-666-4266.
    f. DECNet        DEC.
    g. SNA           IBM.
    h. Novell(IPX)   Built on XNS; rest is designed by Novell.
    i. FDDI          ANSI; 1-212-642-4900.
                      Also Global Engineering Documents; 1-800-854-7179.
                      2805 McGaw Avenue; PO Box 19539; Irvine, CA 92714;
                      1-714-261-1455.
    j. CCITT         United Nations book shop in New York
                      Some of the documents are available via ftp from
                      world.std.com & ftp.uu.net & other sites.
    k. GOSIP         NTIS Sales Dept; [phone]; Document
                      FIPS 146-1; See also Anonymous FTP-based Archive
                      Sites
    l. XNS           Xerox.

  12. Useful Free Software
     (see also RFC1470; listed above)

    a. CUTCP           (TCP/IP client for PCs) sun.soe.clarkson.edu,
                        omnigate.clarkson.edu
    b. NCSA Telnet     (Telnet clients for PCs & Macs) ftp.nsca.uiuc.edu
    c. Eudora          (POP3 Client for Macs) ux1.cso.uiuc.edu
    d. POPmail         (POP3 Client for PCs & Macs)
                        boombox.micro.umn.edu
    e. PCROUTE         (Makes IP router out of PC) accuvax.nwu.edu
    f. PCBRIDGE        (Makes bridge out of PC) accuvax.nwu.edu
    g. Packet Drivers  (Drivers for various PC LAN cards)
                        oak.oakland.edu

    h. WinQVT          (IP clients for Windows) ftp.cica.indiana.edu
    i. ka9q            (TCP/IP for PCs and Macs) ucsd.edu
    j. PC/IP           (TCP/IP client for MS-DOS) husc6.harvard.edu
    k. charon          (Pegasus/smtp gateway) omnigate.clarkson.edu
    l. CAP             (AppleTalk for Unix systems) rutgers.edu,
                        munnari.oz.au, gatekeeper.dec.com
    m. Popper          (POP3 server for Unix systems)
                        ftp.cc.berkeley.edu
    n. Trumpet         (PC Newsreader) oak.oakland.edu
    o. bootpd          (Bootp Daemon for Unix) lancaster.andrew.cmu.edu
    p. NUPOP           (POP3 daemon for MS-DOS) ftp.acns.nwu.edu
    q. NETWATCH        (PC Network watching program) netlab1.usu..edu
    r. iupop3          (POP3 server for VMS) mythos.ucs.indiana.edu
    s. Beholder        (PC Network watching program) ?
    t. KarlBridge      (PC-based filter bridge)
                        nisca.acs.ohio-state.edu
    u. Mosaic          (multifacited information/news client)
                        ftp.ncsa.uiuc.edu
    v. Gopher          (client/server information system) boombox?
    w. Pegasus         (Mail client for PCs & Macs) risc.ua.edu
    x. Kermit          (terminal emulator) Columbia U
    y. netatalk        (AppleTalk for UNIX Systems)  terminator.rs.itd.umich.ed
u    z. etherman        (X-based Ethenet monitoring) ftp.cs.curtin.edu.au
    aa. interman        (X-based IP monitoring) ftp.cs.curtin.edu.au
    bb. packetman       (Ethernet packet analyzer) ftp.cs.curtin.edu.au

  13. Books

    The following books were mentioned by responders to the 12/93
    BIG-LAN Reader Survey as good books for administrators of
    Campus-sized LANs:

    a. Douglas Comer.  Internetworking with TCP/IP.
    b. Albitz & Liu.  DNS and BIND.
    c. Mark Miller.  Troubleshooting Internetworks.
    d. Ed Kroll.  The whole Internet.
    e. Marshall Rose.  The Simple Book.
    f. Craig Hunt.  TCP/IP Network Administration.
    g. Andrew Tanenbaum.  Computer Networks.
    h. Nemeth, Snyder & Seebass.  Unix System Administration Handbook.
    i. Stevens.  Unix Network Programming
    j. Martin A. W. Nemzow.  Keeping The Link (McGraw-Hill).
    k. Interconnections.  Radia Perlman
    l. Inside AppleTalk.
    m. Caroline Arms.  Campus Networking Strategies.  Digital Press.
        Out of print.

    Also mentioned were books published by O'Reilly in general.

  14. Periodicals

    The following periodicals were mentioned by responders to the 12/93
    BIG-LAN Reader Survey as good periodicals for administrators of
    Campus-sized LANs:

    a. Network World
    b. Data Communications
    c. LAN Magazine
    d. LAN Times
    e. Communications Week
    f. PC Week
    g. Network Computing
    h. InfoWorld
    i. ConneXions
    j. Byte
    k. Unix World
    l. Macworld
    m. MacWEEK
    n. PC Magazine
    o. Open Systems Today
    p. Network Management
    q. Lightwave

  15. Training Courses

    The following providers of tutorials were mentioned by responders
    to the 12/93 BIG-LAN Reader Survey:

    a. Interop Tutorials
    b. Cisco training
    c. Westnet training
    d. Network World: Understanding SNMP
    e. Trellis training
    f. TC3 Land/Wan Video
    g. TC3 NetWare 3.11
    h. PDA Data Communications
    i. Hewlett-Packard free seminars
    j. Fred Prior Project Management Seminars
    k. CRAY Research training program
    l. Banyan training

  16. Conferences

    The following conferences were mentioned by responders to the 12/93
    BIG-LAN Reader Survey as good conferences for administrators of
    Campus-sized LANs:

    a. Interop
    b. EDUCOM
    c. Networld
    d. Comnet
    e. Association of Banyan Users International
    f. ACUTA

IV. Basic Glossary on Campus Networks

   Another glossary is RFC1208.  See "Online Papers" above.

     100BASE-T - A set of proposals to the IEEE 802.3 for 100Mbps
       Ethernet, called 100BASE-TX, 100BASE-TF, and 100BASE-T4.  A
       medium-independent interface and an adaptor is planned (to be
       used like the AUI and MAU of 10Mbps 802.3).  This is being
       developed & promoted by the Fast Ethernet Alliance.

     100BASE-T4 - Proposed IEEE 802.3 standard for a 100Mbps
       Ethernet-like network.  One of the flavors of "100BASE-T"
       proposed by the Fast Ethernet Alliance.  Uses 8B6T encoding and
       25MHZ clocking, and in addition to the two pairs traditionally
       used in the manner of 10BASE-T, also has two pair used in
       bidirectional half-duplex fashion.  Among other things, this
       means that this particular kind of Ethernet cannot be made full
       duplex without the use of more pair.  Formerly called 4T+.

     100BASE-TF - A proposal to IEEE 802.3 for a 100Mbps Ethernet-like
       network.  Borrows the physical characteristics of FDDI's
       multimode fiber PMD, but uses Ethernet framing & CSMA/CD.  One
       of three flavors of "100BASE-T" proposed by the Fast Ethernet
       Alliance.  Formerly part of 100BASE-X proposal.

     100BASE-TX - A proposal to IEEE 802.3 for a 100Mbps Ethernet-like
       network.  Borrows the physical characteristics of FDDI's TP-PMD,
       TP-PMD, but uses Ethernet framing & CSMA/CD.  One of three
       flavors of "100BASE-T" proposed by the Fast Ethernet Alliance.
       Formerly part of 100BASE-X proposal.

     100BASE-X - Old name for 100BASE-TF and 100BASE-TX.

     100Mbps Copper UNI - ATM Forum UNI specification for 100Mbps over
       some sort of copper cable.  I believe it is just 100MbpsUNI
       making use of FDDI's TP-PMD rather than the older fiber PMD.

     100Mbps UNI - ATM Forum 100Mbps multimode fiber private UNI.  Same
       as Fore's TAXI.  Borrows optical characteristics & basic
       encoding of FDDI.

     100VG-AnyLAN - "100VG-AnyLAN": Originally a proposal to IEEE 802.3
       for a 100Mbps Ethernet-like network, later relegated to IEEE
       802.12.  Formerly known as 100BASE-VG.  Uses Demand Priority
       media access method and Quartet Signaling.  I've also seen
       reference to its ability to use Category 4 UTP, Category 5 UTP,
       and STP, but I don't know how many pairs.

     100VG-AnyLAN Forum - Group of vendors trying to accelerate
       100VG-AnyLAN acceptance & interoperability.

     10BASE-F - Three variants of IEEE 802.3 which runs over multimode
       fiber.  See 10BASE-FB, 10BASE-FP, and 10BASE-FL.

     10BASE-FB - IEEE 802.3 10BASE-FB: "Synchronous Ethernet" which is
       a special-purpose multimode fiber link for linking repeaters
       that allows the repeaters to communicate more efficiently, thus
       enlarging the count of repeaters that can be placed in series
       above the traditional 4.  Described in IEEE 802.3 Section 17.

     10BASE-FL - IEEE 802.3 10BASE-FL: multimode fiber Ethernet used to
       attach a pair of devices (each being either a host or a
       repeater) as a "Link Segment"--a lot like 10BASE-T except that
       it uses fiber.  It makes FOIRL obsolete.  10BASE-FL transceivers
       can interoperate with FOIRL transceivers.  It is described in
       IEEE 802.3 Section 18.

     10BASE-FP - IEEE 802.3 10BASE-FP: passive star fiber Ethernet.
       Attaches a number of Ethernet devices together with a passive
       star hub (i.e., the hub is not electronic--it just splits the
       light travelling through each incoming fiber to go out all the
       outgoing fibers).  It is described in IEEE 802.3 Section 16.

     10BASE-T - A variant of IEEE 802.3 which allows stations to be
       attached via twisted-pair cable.

     155Mbps UNI - ATM Forum 155Mbps private UNI.  In two flavors:
       multimode and shielded twisted-pair.  The multimode version is
       incompatible with STS3cUNI.  This version is for private
       networks only and presumably will be less expensive.  I heard
       that a C5 version has been proposed.

     25Mbps UNI - IBM proposed copper interface for ATM that so far as
       been rejected by the ATM Forum.  IBM's proposal that borrows
       some of Token Ring's signaling characteristics.  I've read the
       statement that the ATM Forum doesn't support this proposal.

     4T+ - Old name for 100BASE-T4.

     51Mbps UNI - I don't know the actual name.  ATM Forum 51Mbps UNI
       for Category 3 UTP.  Uses AT&T's 16-CAP (a 16 constellation
       modem-type modulation scheme) line coding to transmit the
       signal.  The transmission convergence layer (framing) conforms
       to the STS-1 SONET standard.

     802, 802.x - see IEEE 802, IEEE 802.x.

     ANSI "American National Standards Institute" - A definer of
       standards of all kinds, including FDDI.

     ANSI X3 - ANSI group developing standards for information
       processing.

     ANSI X3T9 - ANSI group within X3 developing standards for I/O
       interfaces.

     ANSI X3T9.3 Committee - ANSI group within X3T9 standardizing HiPPI.

     ANSI X3T9.5 Committee - ANSI group within X3T9 that standardized
       FDDI, PMD, SMF-PMD, and is standardizing TP-PMD and LCF-PMD.

     AppleTalk - A protocol family developed by Apple Computer to
       implement LANs serving Macintoshes.

     ATM "Asynchronous Transfer Mode" - a method for switching little
       fixed-size packets (cells) around.  Like T1 and DS3, digitized
       voice was a major consideration in its design, but it can be
       used for data.  It can be run at different speeds over different
       media including T1 and DS3 as well as 51Mbps, 100Mbps, 155Mbps
       and 622Mbps standards (see SONET & TAXI).  The fixed cell size
       is 53 bytes.  Though ATM is really designed for voice and WANs,
       there are schemes to use it in LANs.  ATM is a big buzzword
       these days but it is still very new.

     ATM Forum - Non-profit international industry consortium chartered
       to accelerate ATM acceptance & interoperability.

     AUI "Attachment Unit Interface" - the Ethernet/IEEE 802.3 term for
       the interface between a MAU and a station.  A special kind of
       cable known as an "AUI Cable" can attach a MAU to a station at a
       distance (up to 50 meters).

     Backbone - a fairly nebulous term for a part of the network that
       interconnects other parts of the network.  For example, a campus
       might have an FDDI ring that interconnects a number of
       Ethernets.  The FDDI ring could be called the network's
       backbone.

     BNC Connector "Bayonet Neill-Concelman connector" - a type of
       connector used for attaching coax cable to electronic equipment
       which can be attached or detached quicker than connectors that
       screw.  ThinWire Ethernet (IEEE 802.3 10BASE2) uses BNC
       connectors.

     Bridge - A network "relay" which reads, buffers, and sends data to
       relay it from one data link to another, but makes the two data
       links appear as one to levels higher than the data link layer.

     Category 3 Unshielded Twisted Pair - standardization of unshielded
       twisted pair cable for voice use.  Some data communications
       standards such as 10BASE-T can utilize it.

     Category 4 Unshielded Twisted Pair - standardization of unshielded
       twisted pair cable.

     Category 5 Unshielded Twisted Pair - standardization of unshielded
       twisted pair cable for data use.  TP-PMD requires Category
       5 cable rather than Category 3.

     CDDI "Copper Data Distribution Interface" - Commonly used term
       for TP-PMD, but actually a trade name of Crescendo.

     Cell - An ATM 53-byte cell.  Note: there are various proposals for
       how typical packets will be broken into cells and restored.

     Cell Switching - a term for ATM-style networks.  See "ATM".

     CMIP "Common Management Information Protocol" - An OSI protocol
       for management of network equipment.  Not widely implemented.
       See SNMP.

     CMOT "CMIP over TCP/IP" - A protocol consisting of CMIP running
       under TCP/IP.  An alternative to SNMP.

     Coaxial Cable - any of a number of kinds of electrical
       communications cable designed so one conductor is in the center
       and the second conductor forms a ring around it.  Depending upon
       who you talk to, someone might have a specific kind of coaxial
       cable in mind.  Some well known kinds are various Cable TV
       cables, cables used by IBM 327x terminals and ARCNet, and cables
       used by Ethernet & IEEE 802.3.

     Collapsed Backbone - a network backbone that is located in a
       single room.  It might be a single router or multiport bridge,
       or a small LAN of some sort.  A typical collapsed-backbone-
       style campus LAN might consist of Ethernets in a number
       of buildings, each with a repeated fiber link into a single room
       at a central point where a router interconnects them.  An
       example of the opposite would be putting a router in each
       building and interconnecting them all with a big FDDI ring.

     Concentrator - a device which allows a number of stations to
       be connected to a LAN.  In the case of Ethernet, it is
       simply a multi-port repeater.  In the case of ring networks
       like Token Ring and FDDI, it acts as a switch which keeps
       the ring intact even if individual devices are unplugged.

     Counterrotating Ring - (see Ring, FDDI, Token Ring) a method of
       using two ring networks going in opposite directions to provide
       redundancy.  The network interfaces can change the path of the
       ring that the data flows around, thereby preserving the ring
       (thus the operation of the LAN) even if some of the cable is
       uplugged or cut, or if a device on the ring fails in such a way
       that it can't transmit data around the ring.

     DECNet - Trade name of Digital Equipment Corporation for some
       of their networking products.  It is a kind of network
       built out of Digital Equipment Corporations own networking
       protocols (with some standard protocols also used).

     Dialup Modem - Modem used over ordinary dial-up telephone lines
       as opposed to private or leased lines.

     DS3 UNI - ATM Forum DS3 UNI, 44.236Mbps.  Also called HSSI?

     DXI - ATM Forum "Data Exchange Interface".

     Ethernet - LAN data-link protocol developed by a consortium
       of vendors; later standardized as IEEE 802.3 with a few
       modifications.  For many applications, users have not adopted
       all the IEEE 802.3 differences.  Ethernet/802.3 now can be
       run on two types of coaxial cable as well as multi-mode
       fiber and unshielded twisted-pair.  "Raw" rate of data
       transmission is 10 megabits/second.

     Fast Ethernet Alliance - Group of vendors working on a 100Mbps
       version of IEEE 802.3.  They intend to submit their proposals
       for approval by the IEEE for a new set of 802.3 standards called
       100BASE-T.

     FDDI "Fiber Data Distribution Interface" - LAN data-link protocol.
       Designed to run on multi-mode fiber.  "Raw" rate of data
       transmission is 100 megabits/second.  Developed by the American
       National Standards Institute.

     FDDI-2 - Same speed, same fiber, same basic protocol as FDDI.
       FDDI-2 adds a layer which allows you to allocate fixed bandwidth
       to applications of your choice, making it more like broadband.
       FDDI-2 is still rather new.

     FDSE - Full Duplex Ethernet: a variant of Switched Ethernet which
       does not use CSMA/CD, but uses slightly-modified network
       interface cards to send & receive packets simultaneously.
       Presumably based on 10BASE-T for most clients, and cannot be
       based on ThinWire or ThickWire Ethernet.

     Fiber - optical fiber: a very long, narrow, flexible piece of
       glass.  Used for high-speed communications.

     Fibre Channel - an ANSI standard to replace HiPPI.  It uses optical
       fiber instead of copper cables.  Speeds are up to roughly
       1Gbps.

     Fibre Channel Systems Initiative - Group of vendors trying to
       accelerate Fiber Channel acceptance & interoperability.  Members
       include: HP, IBM, Sun.

     Firewall Router - a router which blocks traffic according to
       various criteria for security--for example a router which
       allows no telnet to any host through one of its interfaces
       but allows ftp to a list of authorized hosts through the
       same interface.

     FOIRL "Fiber Optic Inter-Repeater Link" - a standard for running
       IEEE 802.3 over fiber, linking two devices (each either a host
       or a repeater) as a "Link Segment".  It has been replaced by
       10BASE-FL.

     FTP - Protocol in the "TCP/IP" family for copying files from
       one computer to another.  Stands for "File Transfer Protocol".

     Full Duplex Switched Ethernet Consortium - Group of vendors that
       are working out the details of FDSE.  Cabletron is a member.

     Full Duplex Token Ring - IBM scheme to add switching to token-ring
       hubs that would allow full-duplex linking to individual
       computers using modified token-ring adaptors.  Has the same
       wiring characteristics as token ring.

     Gateway - A type of "network relay" that attaches two networks
       to build a larger network.  Modern "narrow" usage is that it
       is one that translates an entire stack of protocols, e.g.,
       translates TCP/IP-style mail to ISO-style mail.  Older usage
       used it for other types of relays--in particular, in the "TCP/IP"
       world, it has been used to refer to what many now insist is
       a "router".

     GOSIP "Government Open Systems Interconnect Profile" - A subset of
       OSI standards specific to US Government procurements, designed
       to maximize interoperability in areas where plain OSI standards
       are ambiguous or allow options.  Theoretically, required of all
       US Government networking procurements since mid-1990.

     Heartbeat - In Ethernet (Version 2), a test of the collision
       functionality of the transciever.  The term "Heartbeat" is often
       (wrongly) used interchangeably with "SQE" which is a similar
       function of IEEE 802.3.  See Question on SQE/Heartbeat below.

     HiPPI - "High Performance Parallel Interface", ANSI draft standard
       X3T9.3.

     HSSI "High Speed Serial Interface" -

     Hub - a nebulous term, typically applied to a multiport repeater
       or concentrator consisting of a chassis with slots to be
       populated by cards, allowing it to be configured with various
       numbers and combinations of LAN ports.  Vendors of networking
       equipment often also have other types of devices that can be
       inserted in the slots such as terminal servers, bridges,
       routers, gateways, etc.

     IEEE - Institute of Electrical & Electronic Engineers

     IEEE 802 - The set of IEEE standards for the definition of LAN
       protocols.  A story goes that a long time ago, IEEE and ANSI
       decided that IEEE would get the slow protocols and ANSI would
       get the fast ones, thus IEEE defined the 802 protocols and ANSI
       defined FDDI.  Presumably IEEE saw limited application for FDDI
       at the time.  Also, the IEEE standards-making committees
       associated with these standards.

     IEEE 802 Group within IEEE that standardizes LAN technologies.

     IEEE 802.1 - The IEEE 802 standard for Network Management and
       Network Bridging of IEEE 802 networks.

     IEEE 802.11 - Proposed IEEE 802 group for wireless Ethernet.

     IEEE 802.12 - Group within IEEE 802 working on 100VG-AnyLAN.

     IEEE 802.2 - An IEEE standard for the portion of LAN data-link
       protocols that is the same for all flavors of IEEE LAN
       protocols, e.g.  802.3 and 802.5.  Sometimes not used.

     IEEE 802.3 - An IEEE standard for LANs--their "improved" version of
       Ethernet.  See Ethernet.

     IEEE 802.3 - Group within IEEE 802 that standardizes CSMA/CD LANs.

     IEEE 802.4 - An IEEE standard for LANs: Token Bus networks.
       Basically, standardizes MAP, a protocol that operates a Token
       Bus protocol on broadband.

     IEEE 802.5 - An IEEE standard for Token-Ring-based LANs.  There
       are two types: 4Mbps and 16Mbps.  See also "Token Ring".

     IEEE 802.6 - An IEEE standard for Metropolitan Area Networks.  Also
       known as DQDB.

     IEEE 802.7 - IEEE 802 technical advisory group on Broadband.

     IEEE 802.8 - IEEE 802 technical advisory group on FDDI & fiber
       optics.

     IEEE 802.9 - IEEE 802 group on integrated data & voice networks.

     IMAP "Internet Mail Access Protocol" - TCP/IP-based protocol
       similar to POP, but with additional function designed to handle
       storage of mail on the server rather than the client.  There are
       two versions in common use: IMAP2 and IMAP4.

     IPX - Novell's protocol used by Netware.  Utilizes part of XNS.  A
       router with "IPX routing" purports to interconnect LANs so that
       Novell Netware clients & servers can talk through the router.

     LCF-PMD - FDDI "Low-Cost Fiber" PMD.  Less expensive than PMD.  I
       don't believe it is common nor is it finished as a standard.

     MAU "Media Adaptor Unit" - an IEEE 802.3 or Ethernet device which
       attaches a station to the cable.  Popularly called a
       "transceiver".  Can be attached by cable to the station or built
       into the station.

     MIB "Management Information Base" - the set of parameters an SNMP
       management station can query or set in an SNMP agent (e.g.
       router).  Standard, minimal MIBs have been defined (MIB I, MIB
       II), and vendors often have custom entries.  In theory, any SNMP
       manager can talk to any SNMP agent with a properly defined MIB.

     Multimode fiber - A type of fiber mostly used for shorter, e.g.
       campus distances.  It can carry 100 megabits/second for typical
       campus distances, the actual maximum speed (given the right
       electronics) depending upon the actual distance.  It is easier
       to connect to than Single Mode Fiber, but its limit on speed x
       distance is lower.

     NFS "Network File System" - an IP-based protocol originally
       developed by Sun Microsystems which provides file services.

     OCx - (e.g. OC1, OC3) variants of SONET.

     OSI "Open System Interconnect" - A standard put forth by the ISO
       for communication between computer equipment and networks.

     OSI Reference Model - A model put forth by the ISO for
       communication between computer equipment and networks, which
       maps out 7 protocol layers.

       Top layer:    layer number 7:   application layer
                     layer number 6:   presentation layer
                     layer number 5:   session layer
                     layer number 4:   transport layer
                     layer number 3:   network layer
                     layer number 2:   data-link layer (e.g. IEEE 802.x)
       Bottom layer: layer number 1:   physical layer (wire &
                                        electricity)

       This model explains what each layer does.  The model is often
       used to explain anyones protocols (not just OSI) to the point
       where many people seem to believe that true data-communications
       requires these 7 layers.

     PMD - FDDI "Physical Layer Medium Dependent" part.  When "PMD" is
       used by itself, it may refer to the usual kind of FDDI physical
       layer that uses multimode fiber.  Note that FDDI terminology
       also uses it as a more generic term, referring to different FDDI
       PMD's such as TP-PMD and SMF-PMD.

     POP "Post Office Protocol" - A TCP/IP-based protocol designed to
       allow client-stations (e.g. micros) to read mail from a server.
       There are three versions under the name "POP": POP, POP2, and
       POP3.  Latter versions are NOT compatible with earlier
       versions.

     Protocol - The "rules" by which two network elements trade
       information in order to communicate.  Must include rules about a
       lot of mundane detail as well as rules about how to recover from
       a lot of unusual communication problems.  Thus they can be quite
       complicated.

     Relay - One terminology uses the term "relay" as a device that
       interconnects LANs, different kinds of relays being repeaters,
       bridges, routers, and gateways.

     Repeater - In the "Ethernet" world, a "relay" that regenerates and
       cleans up signals, but does no buffering of data packets.
       It can extend an Ethernet by strengthening signals, but timing
       limitations on Ethernets still limit their size.

     RFC "Request For Comments" - The name is a real red herring when
       it comes to Internet RFCs.  Some really are "Requests For
       Comments" but all Internet protocol documents are stamped with
       an RFC number that they never shake, so the acronym RFC
       generally refers to documents that describe protocols in the
       TCP/IP family.

     RG numbers (E.g. RG62; sometimes there are qualifiers, e.g. RG 58
       A/U) a shorthand designation for military cable.  RG58 & RG62
       designate two different types of cable used by the military.
       Some data-communications equipment was designed to work with
       a particular military standard, e.g.  IBM 3270-type terminals
       use RG62.  In other cases, people use an RG-numbered cable
       that is close to what they need: for example ThinWire
       Ethernet & IEEE 802.3 10BASE2 define the type of cable they
       need and people sometimes substitute flavors of RG58, which
       are "close".  One can't recommend this practice because you
       can get yourself in trouble.  I think "RG" originally stood
       for "Radio Guide", presumably reflecting the fact that the
       series of cables was designed to handle radio frequencies.  The
       IEEE 802.3 10BASE2 specifications define two RG numbered cables
       (RG58 A/U and RG58 C/U) as meeting the cable requirements for
       thin Ethernet.  However, cable vendors may list a range of
       cables under these same RG numbers, and some of the cables
       listed may not meet the 802.3 specs.  You need to check the
       cable specifications closely, and beware of relying on the RG
       number alone when ordering network cables.

     Ring - A classification of network technology exemplified by
       Token Ring and FDDI.  The interconnected devices are connected
       one-to-another in the shape of a ring and data flows around
       it in one direction.  See also "Counterrotating Ring".

     RJ numbers ("Regestered Jack" numbers, e.g. RJ11, RJ45) - numbers
       applied to types of connectors often used in UTP wiring.
       Borrowed from voice telecommunications industry.

     Router - A network "relay" that uses a protocol beyond the
       data-link protocol to route traffic between LANs and other
       network links.

     Routing Protocol - a protocol sent between routers by which
       routers exchange information own how to route to various parts
       of the network.  The TCP/IP family of protocols has a bunch,
       such as RIP, EGP, BGP, OSPF, and dual IS-IS.

     SDH "Synchronous Digital Hierarchy" - Similar to SONET, but used
       outside North America.  Some of the SDH and SONET standards are
       identical.  Standardized by the CCITT.

     Shielded Twisted Pair - a type of twisted-pair cable with a
       metallic shield around the twisted conductors.  The shield
       reduces the noise from the cable and reduces the effects of
       noise on the communications in the cable, but changes the
       electrical characteristics of the cable so some equipment
       optimized to non-shielded cable runs worse on shielded cable.

     Single Mode fiber - a type of fiber optic cable used for longer
       distances and higher speeds, e.g.  for long-distance telephone
       lines.  See also "Multimode Fiber".

     SMF-PMD - FDDI "Single-Mode Fiber" PMD.  Runs further than PMD.

     SMTP "Simple Mail Transfer Protocol" - the protocol in the
       TCP/IP family used to transfer electronic mail between
       computers.  It is not oriented towards a client/server system so
       other protocols (see "POP") are often used in that context.
       However, servers will use SMTP if they need to transfer a
       message to another server.

     SNMP "Simple Network Management Protocol" - Originally developed
       to manage IP based network equipment like routers and bridges,
       now extended to wiring hubs, workstations, toasters, jukeboxes,
       etc.  SNMP for IPX and AppleTalk under development.  Widely
       implemented.  See CMIP.

     SONET "Synchronous Optical Network" - A set of standard
       fiber-optic-based serial standards planned for use with ATM in
       North America.  Developed by Bellcore.  Different types of SONET
       run at different speeds (OC1 runs at 51Mbps, OC3 runs at
       155Mbps, OC12 runs at about 600Mbps, OC48 runs at over 2Gbps),
       and use different types of fiber (OC3 has several variants for
       use with different fibers & different distances; there are
       versions for both single mode and multimode fiber).

     SQE Test "Signal Quality Error Test" - an IEEE 802.3 function
       that tests the transceiver.  The term "SQE" is often (wrongly)
       used interchangeably with "Heartbeat" which is a similar
       function of Ethernet Version 2.  See Question on SQE/Heartbeat
       below.

     STP - Shielded Twisted Pair

     STS-3c UNI - ATM Forum SONET STS-3c UNI, 155.52Mbps.

     Switched Ethernet - really the same as Ethernet as far as
       standards go: acts like a very fast multiport Ethernet bridge
       giving an Ethernet to each station.  Presumably based on
       10BASE-T for most stations.

     Switched FDDI - really the same as FDDI as far as standards
       go: acts like a very fast multiport FDDI bridge.  Basically the
       DEC GigaSwitch.

     T1 - A phone-company standard for running 24 digitized voice
       circuits through one 1.5megabit/second digital channel.  Since
       phone companies run lots of T1, and will run T1 between customer
       sites, the standard is often used for data communications,
       either to provide 24 low-speed circuits, or to provide 1
       high-speed circuit, or to be divided other ways.

     TAXI - "Transparent Asynchronous Transmitter-Receiver Interface"
       Two ATM UNI specifications developed by Fore.  The slower one
       ran at 100Mbps and borrowed the physical characteristics of FDDI
       and has been adopted by the ATM Forum as its 100Mbps UNI
       specification.  The faster one ran at 140Mbps.

     TCP/IP "Transmission Control Protocol/Internet Protocol" -
       literally, two protocols developed for the Defense Data Network
       to allow their ARPANET to attach to other networks relatively
       transparently.  The name also designates the entire family of
       protocols built out of IP and TCP.  The Internet is based upon
       TCP/IP.

     TELNET - a protocol in the TCP/IP family that is used for
       "remote login".  The name is also often used as the name of the
       client program that utilizes the TELNET protocol.

     Terminal Server - a network device that allows a number of
       terminals to attach to a LAN, and do remote logins across the
       LAN.

     ThickWire - "ThickWire" Ethernet or IEEE 802.3 10BASE5.

     ThinWire - ThinWire Ethernet or IEEE 802.3 10BASE2.

     TN3270 - A variant of the TELNET program that allows one to
       attach to IBM mainframes and use the mainframe as if you had a
       3270 or similar terminal.

     Token Ring - People often use the term "Token Ring" to designate
       IEEE 802.5 (see above).  In the more general sense of the
       phrase, a token ring is a type of LAN that has stations wired in
       a ring, where each station constantly passes a special message
       (a "token") on to the next.  Whoever has the token can send a
       message.

     TP - "Twisted Pair".

     TP-PMD - FDDI "Twisted Pair Physical Layer Medium".  ANSI
       specification for FDDI-like service over UTP.  Being
       standardized by ANSI X3T9.5.  Was X3T9/93-130 X3T9.5/93-022
       TP-PMD/306 Rev 2.0, now there is a Rev 2.1.  Uses MLT-3 encoding
       instead of CDDI's NRZI encoding.

     Tunneling - An important concept in the design of many kinds of
       networks: taking some protocol-family's ability to move packets
       from user to user, or to open virtual-circuits between users,
       and use this as if it were a data-link protocol to run another
       protocol family's upper layers (or even the same protocol
       family's upper layers).  Examples: running TCP/IP over AppleTalk
       instead of something like Ethernet; running AppleTalk over
       DECNet instead of something like Localtalk or Ethernet.

     Twisted Pair - The type of wire used by the phone company to wire
       telephones -- at least over distances like between your house
       and the central office.  It has two conductors, which are
       twisted.  The twists are important: they give it electrical
       characteristics which allow some kinds of communications
       otherwise not possible.  Ordinary telephone cables are not
       shielded (see "Shielded twisted Pair").

     Type1 - IBM Type 1 STP.  The most usual type of Shielded Twisted
       Pair in LAN communications.

     UNI - ATM Forum "User to Network Interface".  See ATM.

     UTP (Unshielded Twisted-Pair) -  See "Twisted-Pair" and "Shielded
       Twisted-Pair".

     X.400, X.500 - OSI protocols for mail and directory services.

V. Frequently Asked Questions on Campus Networks

     It is hard to answer typical BIG-LAN questions in advance for two
     reasons.  Answers are often long and they are often
     controversial.  To provide some sort of objective information
     relevant to the controversies, a survey of BIG-LAN readers was
     taken on answers to various questions, so this memo could offer a
     sampling of opinions.  Note that the opinions below are extracted
     from the 41 responses received for the survey.  We can't say these
     41 responses represent a fair sampling of campus LAN
     administrators, but they do show some of the answers that you
     would get if you posed some of these questions to the BIG-LAN
     readership.

  1. What is the difference between Ethernet and IEEE 802.3?

     Ethernet ran through an evolution starting with some experimenting
     at Xerox, and ending with a standard published by Xerox, DEC, and
     Intel, which they offered to the world (with minimal royalties) as
     a standard technology for building LANs.  The Institute of
     Electrical & Electronic Engineers took this as a proposed
     standard, and rewrote the protocol description making some
     clarifications and a few changes.  Some of the changes have been
     universally adopted, and others have not.  After the first go
     round of IEEE standard defining, Ethernet version 2 was introduced
     which brought it more into line with standards.  The basic
     differences are:

         - Heartbeat vs SQE (see below) - Which pin in the MAU & AUI
         connectors carry the ground conductor - Packet Length Field vs
         Type Field

     The latter issue is the one in which IEEE 802.3 has not displaced
     Ethernet.  Ethernet had a 16-bit field which defined the type of
     packet (examples: IP, XNS, AppleTalk).  The IEEE committee decided
     to use that field to specify the length of the packet, and have
     the data-portion of the packet define itself through the next
     higher level of protocol (e.g., IEEE 802.2).  However, the sets of
     possible values for that field used by the two different protocols
     are completely separate, and both protocols are designed to
     deliberately ignore packets with fields outside their own sets of
     values.  Thus Ethernet and IEEE 802.3 packets can coexist on the
     same cable, though a computer which expects to get packets
     belonging to just one of the protocols won't notice any packets
     sent according to the rules of the other (the expression used is
     "they pass by each other like ships in the night").

     These days, LANs use both.  There is a way to send TCP/IP packets
     via 802.3, but when 802.3 was introduced, there were already so
     many systems using the Ethernet rules that the use of
     Ethernet-style packets for TCP/IP has persisted now for years.

  2. What is encapsulation?  What do I have to know about it?

     One encapsulation issue on LANs is whether IEEE 802.3 packets are
     used or Ethernet packets are used to encapsulate your traffic on
     your IEEE 802.3/Ethernet LAN.  See previous question for more
     explanation.  Most TCP/IP systems use Ethernet, any that uses IEEE
     802.3 by default might surprise you by not interoperating with the
     rest of your TCP/IP network.

     A second encapsulation issue on IEEE 802.3/Ethernet networks is
     whether your Novell (IPX) packets use Novell's default
     encapsulation or whether they use Ethernet-style encapsulation.
     Novell, at least for a long time, had the distinction of using
     IEEE 802.3 as if it were the only protocol on the network, not
     following the rules for avoiding other protocols running under
     IEEE 802.3 rules.  They offered a utility called ECONFIG that
     changed Netware to use Ethernet rules, and use them properly, so
     Novell IPX packets could utilize the same LAN as other protocols.
     In no case would the Novell traffic bother Ethernet traffic-- only
     any other IEEE 802.3 traffic if ECONFIG wasn't used.  In any case,
     a single Ethernet segment, or bridged segments, had to have all
     Novell servers and clients configured the same, in order to
     interoperate.

     A third encapsulation issue stems from Berkeley Unix 4.2, from
     which many versions of Unix and many TCP/IP implementations have
     been modeled.  It used, by default, its own encapsulation rules
     (i.e., manner of putting IP packets within Ethernet packets) which
     is termed "Trailer Encapsulation".  When an Ethernet had some
     computers using Trailer Encapsulation and some not, TCP/IP
     connections would often work, but hang when large data transfers
     were taking place.  The next version of Berkeley Unix, version
     4.3, remedied this by avoiding Trailer Encapsulation except when
     it was guaranteed to work correctly.

     A fourth encapsulation issue is "tunneling", which consists of
     one of the layers in the protocol stack mimicking another layer to
     provide a way of running a different set of upper layers than
     would otherwise be possible.  This is rather widely used and
     seldom explained to beginners.  It is perhaps best explained with
     an actual example:

[Here put an example, perhaps AppleTalk over IP]

[Include "encapsulated bridging" as a second example]

  3. How do I know whether to use a router or a bridge?

     (Note that the answer to this question is oriented to
     Ethernet-based LANs).  Few administrators of networks doubt that a
     network can be large enough to require routers nor that there are
     situations where a bridge is an effective solution.  However,
     there is controversy as to where to draw the line.  Campus-sized
     networks involving distances of up to a mile and possibly
     thousands of stations, can be, and have been built solely out of
     one or the other.  The BIG-LAN Survey of 12/93 showed the
     following opinion among respondents:

       Survey question: "When you build a campus network, do you tend
       to use bridges as opposed to routers?"

       Answers: 13 said yes; 45 said no; 10 said some of each.

     Some clear tradeoffs: routers generally have to be set up no
     matter what whereas bridges can be plug-and-play on a network
     without too much total traffic; bridges generally have a higher
     speed-to-cost ratio and the low-end bridge is less expensive than
     the low-end router; routers handle huge networks with links of
     different speeds better.

  4. How do I know whether to use a bridge or a repeater?  How many
     repeaters may I put on an Ethernet?

     [Note: with the advent of 10BASE-F, this section needs updating.
     -ed]

     You cannot keep plugging more repeaters and add more cables to an
     Ethernet indiscriminately and expect it to work.  With too large a
     networks, the protocol which keeps the number of collisions down
     (known as CSMA/CD) fails to do that.  The protocol documents
     supply rules-of-thumb which, if followed, prevent this from
     occurring.  If you break them, you may be risking large
     performance degradations.

     The latest version of the rules-of-thumb (which have been updated
     over time as new features like 10BASE-T have been added to the
     protocol) are in the IEEE 802.3 document describing 10BASE-T,
     specifically IEEE Std 802.ei-1990 in the section called "System
     Considerations for Multisegment 10 Mb/s Baseband Networks".
     The rules refer to the piece of the LAN that is between repeaters
     as a segment and refer to 4 kinds: 10BASE5 (i.e. "classic"
     Ethernet) and 10BASE2 (i.e., ThinWire Ethernet) both classified as
     "Coax" segments and FOIRL (fiber inter-repeater links) and
     10BASE-T, both classified as "Link" segments, and both of which
     have the property that you can attach things only to their ends.
     The basic repeater rule is that between any two stations on the
     LAN, there may be at most 4 repeaters and three coax segments.  In
     addition, there are length restrictions on the segments which are
     designed to keep CSMA/CD working properly:

        10BASE5         500 meters
        10BASE2         185 meters
        FOIRL           500 meters (1000 meters in some cases)
        10BASE-T        100 meters (or more)

     FOIRL links can be 1000 meters if you have at most 3 repeaters
     between stations instead of 4.  10BASE-T links can be longer if
     the cable will support it: CSMA/CD is not the limiting factor on
     10BASE-T.  For the purposes of this discussion, bridges, routers,
     and gateways are "stations" since the CSMA/CD protocol does not
     pass through them.  Thus if you discover these rules prevent you
     from putting a repeater in the network where you need one, then
     you can put a bridge there instead, or perhaps split the LAN
     somewhere else using a bridge.

  5. Should I use "manageable" hubs, concentrators, etc on my LAN?

     This is a controversial question also.  Vendors have attempted to
     make hubs and concentrators that require little training &
     manpower to manage & troubleshoot, and they will attempt to
     convince you that they have succeeded.  You pay a premium for
     "manageability".  Those who remain skeptical wonder how much the
     management features are ever used: for example, management allows
     you to turn on & off ports from an operator's console; how often
     do you need to do such a thing?  Also, some of the benefits
     attributed to management packages are simply due to good record
     keeping, something which the administrator must find the manpower
     to accomplish with a management package or without one (presumably
     with a simple dbms, which can often be tailored more to the
     administrators needs).

  6. Which LAN technology should I use?  Arcnet?  FDDI?  Token Ring?
     10BASE-T?

     A controversial question.  Some questions & answers from the 12/93
     BIG-LAN Reader Survey:

       "When you install a LAN, which "Technology" (e.g.  Ethernet,
       Token Ring) do you prefer?"

       All respondents said Ethernet through three also said FDDI
       is good.

       "If you have experience with two or more LAN technologies, which
       have you found works better?"

       Answers received:
       Ethernet works best                18
       10BASE-T is best                    6
       Ethernet & FDDI work best           3
       Ethernet is better than Token Ring  2
       Ethernet costs less than FDDI       2
       Localtalk better than 10BASE-T      1
       FDDI is best                        1
       Ethernet is better than Pronet-10   1
       Ethernet is better than ARCNet      1
       Ethernet is better than PhoneNet    1
       Ethernet followed by FDDI           1
       Ethernet & Token Ring equal         1
       Depends on how they are maintained  1

  7. What is the ideal cable to install in a new building?

     Distribution runs, i.e., phone closet to room: Best possible thing
     to do is to leave usable pathways for future expansion.  Whatever
     you do, install at least 2 pair and probably 4 pair of data grade
     unshielded twisted pair.  It will always have uses.  Install
     something else too if you are tied to a particular vendor.
     Multimode fiber might become popular in the future but that is a
     gamble.

     Riser runs, i.e., phone closet to phone closet: it is imperative
     to leave usable pathways for future expansion.  For Ethernet,
     ThinWire is a usable riser cable, multimode fiber is possible
     too.

  8. What is the ideal cable to install between buildings on a campus?

     Trunks, i.e., cables into the building: pathways for future
     expansion very valuable.  Multimode fiber is useful, run 24 fibers
     if you can.  Use cable with some single mode too.  Run several
     times what you need initially and leave a lot of the unused fiber
     unterminated for the time being.  Cable pulling & termination are
     much more costly than the cable itself.

  9. Whose routers are recommended?

     Question & answer from the 12/93 BIG-LAN Reader Survey:

       "Name some router vendors whose routers you have used and
       recommend:"

       Cisco got 55 mentions; Wellfleet 9; Proteon 8; 3Com 3; Novell 3;
       Xyplex 3; Network Systems 2; DEC 2; HP 2; NAT 2; Retix 1; NAC 1;
       GatorBox 1; Alantec 1; Telebit 1; Fibronics 1; Shiva 1;
       PCRoute 1.

  10. Whose bridges are recommended?

     Question & answer from the 12/93 BIG-LAN Reader Survey:

       "Name some bridge vendors whose routers you have used and
       recommend:"

       DEC got 11 mentions; 3Com 8; Cabletron 5; Retix 5; Xyplex 5; HP
       4; Cisco 3; Gandalf 3; Wellfleet 2; D-link 1; Asante 1; ODS 1;
       Synernetics 1; PlainTree 1; Alantec 1; Artel 1; Develcon 1;
       Gandalf 1; karl-bridge 1; Allied Telesis 1; Vitalink 1; ATT 1.

  11. Whose Ethernet equipment are recommended?

     Question & answer from the 12/93 BIG-LAN Reader Survey:

       "Name some Ethernet concentrator/transceiver/repeater vendors
       whose Ethernet equipment you have used and recommend:"

       Cabletron got 30 mentions; 3Com 15; Allied Telesis 15; HP 13;
       Synoptics 11; Asante 9; Chipcom 8; DEC 7; SMC 7; David Systems
       4; Xyplex 3; Milan 2; Lantronix 2; Gandalf 2; D-Link 2; Canary
       2; ATT 2; BlackBox 2; Hughes 2; Fibermux 2; St. Clair 1;
       Pirelli-Focom 1; Pilkington 1; ODS 1; Networth 1; LANNET 1;
       Kalpana 1; Isolan 1; Interphase 1; Intel 1; IMC 1; Hirschmann 1;
       Fibercom 1; BICC 1.

  12. Whose Token Ring equipment are recommended?

     Query and answers from the 12/93 BIG-LAN Reader Survey:

       "Name some Token Ring equipment vendors whose Token Ring
       equipment you have used and recommend:"

       IBM was mentioned by 12 responders; Proteon 3; ODS 2; UB 1;
       Thomas-Conrad 1; Startek 1; Madge 1; HP 1; Cabletron 1; CSP 1.

  13. Whose FDDI equipment are recommended?

     Query and answers from the 12/93 BIG-LAN Reader Survey:

       "Name some FDDI equipment vendors whose FDDI equipment you have
       used and recommend:"

       Cisco was mentioned by 8 responders; Crescendo 7; DEC 5;
       Synoptics 3; Interphase 3; 3Com 3; Fibronics 2; Cabletron 2;
       Synernetics 1; Sun 1; SGI 1; Proteon 1; PlainTree 1; ODS 1;
       Network Peripherals 1; IBM 1; Fibermux 1; Chipcom 1.

  14. What PC network software is recommended?

     Query and answers from the 12/93 BIG-LAN Reader Survey:

       "Name some PC network software vendors whose PC network software
       you have used or recommend:"

       Novell was mentioned by 32 responders; FTP Software 21; Apple 7;
       SunSelect 6; Microsoft 5; NCSA 4; IBM 4; Banyan 4; DEC 4;
       NetManage 3; Clarkson 3; 3Com 3; Word Perfect 2; WinQVT 2;
       Reflection 2; Qualcomm 2; Brightworks 2; Beame & Whiteside 2.

  15. What protocols should run on a campus-wide LAN?

     Query and answers from the 12/93 BIG-LAN Reader Survey:

       "Name some protocols that you use to interconnect your campus
       that you would recommend:"

       TCP/IP was mentioned by 63 responders; IPX 26; AppleTalk 17;
       DECNet 7; LAT 3; VINES 2; SNA 2; CLNS 1.

  16. What software is recommended for managing a campus-wide LAN?

     Queries and answers from the 12/93 BIG-LAN Reader Survey:

       "Name some network management system that you use for the
       management of a campus LAN, that you recommend:"

       SunNet Manager was mentioned by 13 respondents; HP OpenView 8;
       Cabletron Spectrum 3; Cabletron Remote LanView 3; PSI SNMP 2;
       Netlabs 2; CiscoWorks 2.

       "Name other software that you use for the management of a campus
       LAN that you recommend:"

       Ping was mentioned by 4 respondents; Traceroute 3; SunNet
       Manager 2; Network General Sniffer 2; Neon Software NetMinder 2;
       CMU SNMP 2.

  17. What terminal server is recommended?

     Query and answers from the 12/93 BIG-LAN Reader Survey:

       "Name vendors of terminal servers that you use and recommend:"

       Cisco was mentioned by 21 respondents; Xylogics 12; Xyplex 11;
       DEC 9; Emulex 4; Spider 2; Equinox 2; Netblazer 1; Livingston 1;
       Lantronix 1; HP 1; Datability 1; Digiboard 1; Allied Telesis 1;
       3Com 1.

  18. Whose troubleshooting equipment are recommended?

     Query and answers from the 12/93 BIG-LAN Reader Survey:

       "Name some vendors of network troubleshooting equipment that you
       use and would recommend:"

       Network General was mentioned by 30 respondents; HP 11;
       MicroTest 4; Tektronix 3; Spider 3; Fluke 3; FOTEC 3; W&G 2;
       Novell 2; FTP 2; Exfo 2; Van Jacobson 1; Pentascanner 1; NCC 1;
       NAT 1; LM-1 1; Consultronics 1; Antel 1; AG Group 1.

  19. What security products should I buy?

     Query and answers from the 12/93 BIG-LAN Reader Survey:

       "Name some security products that you use to maintain security
       on your campus LAN that you recommend:"

       COPS was mentioned by 5 respondents; tcpwrapper(s) 3; SecurID 3;
       Crack 3; Cisco access control 2; xtacacs 1; npassword 1;
       Tripwire 1; Socks 1; Netware 1; Native VINES security 1; McAffee
       Anti-Virus NLM 1; HP 1; Bridges 1; Beame and Whiteside 1.

  20. Should the names of devices on my campus LAN have subdomains?

       Example of name without subdomain: bigvax.sequoia.edu; example
       with subdomain: bigvax.acs.sequoia.edu.  It is possible to run
       networks of thousands of computers without the bother of
       subdomains, but they have some advantages.

     Queries and answers from the 12/93 BIG-LAN Reader Survey:

       "For Internet names of nodes on a campus network that supports
       TCP/IP, do you prefer the use of subdomains?"

       49 responders said yes, 11 said no, 3 said it depends.

       "If you have worked on a campus that utilizes subdomains and one
       that does not, which does your experience tell you is the better
       way to administer names in a campus network?"

       13 responders said the LAN with subdomains worked better; 1 said
       the LAN without subdomains worked better; 2 said it doesn't
       matter and 3 said it depends.

  21. Should client stations use POP?  Should they use just SMTP?
      Should I use some non-TCP/IP protocol for mail to/from client
      stations?

     Query and answers from the 12/93 BIG-LAN Reader Survey:

       "For client station's mail, which do you prefer: SMTP;
       TCP/IP-based client-server protocols (e.g.  POP, POP2, etc);
       other LAN protocols?"

       22 responders preferred TCP/IP-based client-server protocols
       (e.g.  POP, IMAP, PCMAIL); 20 preferred SMTP; 5 preferred other
       LAN protocols; 3 said "use all three"; 3 said "SMTP and
       TCP/IP-based client-server protocols"; 3 said "SMTP and other
       LAN protocols"; 1 said "TCP/IP-based Client-server Protocols and
       other LAN protocols".

  22. Should I enable SQE/heartbeat?

     SQE Test (often labeled "SQE" by vendors) is part of IEEE 802.3
     that is designed to test part of the the MAU (transceiver)
     hardware.  It basically consists of the MAU trying out the
     collision signal line immediately after each packet it sends.
     Thus a station on the network can verify that the MAU is working
     by watching for this signal and can log an error for you if the
     signal is not present.  Correct practice is to turn SQE Test off
     on any MAU that is attached to a repeater and turn it on on any
     MAU attached to a station.  Not doing this can lead to incorrect
     repeater operation and/or a lack of logging of serious network
     errors when they occur.

     However, many vendors of networkable stations take no advantage of
     SQE Test (it was new to IEEE 802.3 & Ethernet Version 2, not being
     present in earlier Ethernet) and there have been many reports of
     stations that won't even work properly when it is enabled.  Thus
     your dilemma: some of your users may have stations that won't work
     unless you set your MAU's wrong.  Maybe some day all vendors will
     fall into line, or the IEEE will revise its standard to get rid of
     SQE Test.  In the mean time you are forced to know which stations
     log errors without it and which ones work poorly with it on.
     Examples of computers/networking equipment sensitive (one way or
     the other) to SQE test:

     Definitely can't handle SQE Test:
         No convincing confirmations

     Mixed & inconclusive reports saying they can't handle SQE Test:
         Some Sun workstations
         Cisco routers

     Needs SQE Test or it reports errors (i.e., uses SQE Test as
     intended):
         VAX/VMS
         Alpha/VMS

  23. If I have a thinwire network interface card, how do I connect it
      to a 10BASE-T concentrator?

     Ethernet standard provides only one way to do interconnect
     thinwire (10BASE2) and 10BASE-T: using a repeater (e.g. a
     concentrator).  Since this is expensive and it increases the
     repeater count, thus limiting the expanse of the rest of the
     network, customers want, and several vendors provide adaptors that
     are not real repeaters.  Typically, these allow a 10BASE-T segment
     to end in a shorter-than-usual thinwire segment.  One depends upon
     the vendor to provide instructions as to how its use affects the
     limitations on segment lengths and repeater counts.

  24. How much does a collision slow down an Ethernet packet?

     Perhaps you've noticed the phenomena that you might ask otherwise
     intelligent & knowledgeable network professionals how many
     collisions indicate too much load, and they immediately divert the
     conversation to the question of whether your network is broken.
     The implication is that they're more inclined to believe your
     Ethernet is performing poorly due to being broken than due to load.
     Here's an explanation, probably more than you ever wanted to
     know:

     Coaxial Ethernet was designed so that everyone shares the same
     single cable.  Electrical characteristics of transmission were
     chosen so that when more than one station places bits on the
     network, the voltages in effect "add" and the transceiver can
     sense the "unusual" voltage as a collision.

     Transceivers detect the collisions, and signal the stations by
     raising a "collision detect" line to the station.  According to
     the standard, transceivers signal any collision that occurs when
     it is sending a packet, and also any triple collision.

     The Network Interface hardware takes care of retransmissions and
     reports the collision to the driver.  It might not report complete
     information on the number of collisions--for example, one Ethernet
     chip will report after each packet it sends, whether there were 0,
     1, 2, <16, or >16 Collisions.  The driver usually keeps a count
     that it updates from the information it gets from the card.

     Repeaters do not "recreate" electrical collisions on other
     networks.  Any time the repeater detects a collision, it is, by
     definition, in the midst of transmitting a packet.  It can no
     longer pick up valid data off the net to continue sending the
     packet.  The Ethernet spec says it should start sending 32 bits of
     made-up data (called a JAM) that will make the packet terminate
     early, with a CRC error.  None receiving stations on the other
     side of the repeater will see "collision" signaled by their
     transceiver.  Instead, they will receive just the beginning of a
     packet.  This is called a "runt".  The network interface hardware
     could, theoretically, report a runt as a collision, which might be
     useful for some kinds of monitoring.  Or the software, might
     consider a runt a collision and increment the same count.  Or it
     can count them separately, or not count them at all.  Software
     that reports these separately from collisions usually refers to
     them as runts or JAMs.

     Link segments like 10BASE-T, FOIRL and 10BASE-FL attach only two
     devices and have separate paths in each direction.  Thus
     collisions are superfluous, but must still be detected and
     reported since Ethernet interfaces cannot be assumed to have the
     ability to send and receive packets at the same time.  Thus the
     transceivers watch for packets flowing in both directions at the
     same time, and signal collision to the station as well as produce
     a JAM signal on the line so that the stations trying to send the
     packets will get the message that this was a collision and the
     packet needs to be resent.

     Ethernet interfaces retransmit packets up to 16 times with an
     exponential backoff for the first 10.  The minimum retransmission
     time is relatively quick and the detection process takes a fixed
     amount of time, so 75% of all times that two stations are
     contending for a net are resolved with one station starting a
     successful transmission within 250 microseconds.  It is important
     to realize that Ethernet's collisions are a normal part of
     scheduling the use of the LAN, that it is used only when carrier
     sensing doesn't do the trick, and that Ethernet uses a
     third-generation scheme that handles collisions very smoothly when
     when the hardware works & is properly assembled, even under high
     loads.  A lot of mis-information is spread about collisions, often
     from people dealing with Ethernet's competitors, but also often
     from Ethernet users who simply haven't studied it too closely, or
     listened to the wrong people.

     A collision is always detected & taken care of (to the point of
     starting the backoff) within the first 50 microseconds of a
     packet's transmission on a correctly functioning Ethernet.  Aside
     from helping to limit the time spent dealing with collisions, this
     insures that collisions of even the smallest legal packets are
     always detected.  Some interface hardware reports late collisions,
     i.e. collisions signaled after this time:  unlike collisions,
     which are normal, late collisions are a type of error.  Note that
     on the other side of a repeater, the late collision simply looks
     like a CRC error perhaps with an alignment error.  There are two
     causes of late collisions:  faulty hardware; or the network being
     too large.  In either case, it tells you that the network is
     having a problem, and packets are almost surely being lost
     sometimes, causing unnecessary & occasionally severe performance
     penalties.  If the network is too large, properly placed routers,
     bridges (or some switches) can subdivide it into two
     properly-sized Ethernets.

     Can random collisions cause packets to be lost?  The exponential
     backoff algorithm yields a probability of 50% that a pair of
     colliding packets require more than one retransmission to get
     through if two stations are contending for the net at exactly the
     same time, and only 25% of the ones that still haven't succeeded
     fail to get through after the second retransmission.  For the
     16-retry limit, the calculation of the faction not making it is:

                  1/2 x 1/4 x .... 1/(2*10) x (1/(2*10))**6

     or           (1/2)**115

     or about     (1/10)**34.

     I conclude that on every Ethernet ever installed, for every packet
     sent, that this has never happened (give me a billion LANs that
     transmit a billion packets every day for a billion days and the
     odds are still a million to one against even one lost packet).
     When more than two stations are involved (i.e., more than two
     stations have something to send at exactly the same time), these
     odds aren't so overwhelming--thus I conclude that there have
     indeed been packets lost on correctly functioning Ethernets
     somewhere (Note:  also the randomness of the backoff is probably
     not perfect and I've heard of network interfaces that illegally
     stop before 16 retries!).  Recall also that stations do sense
     carrier: collisions only resolve the problem of what happens when
     the packets start at almost the same time.  Probably the most
     usual time for a collision is when two stations simultaneously see
     the end of a packet, both having a packet to send.  In this case,
     there will be more than one collision on average, but as stated
     above, 75% of the time, one of them will have started a successful
     transmission within 250usec.

     In contrast to the smooth handling of properly detected
     collisions, an undetected collision causes a packet to be lost,
     which must be retransmitted by software:  for example NFS is often
     set to time out at .5 seconds, so a lost packet (for example, the
     result of an undetected collision) causes a delay typically 2000
     times longer.  Networks with problems that cause undetected
     collisions, frequent unnecessary collisions, or lose packets for
     other reasons are much worse performance killers than collisions
     caused by an increase in load.

     How many packets can you tolerate an Ethernet losing?  1 in 100?
     1 in 1000?  1 in 10,000?  1 in 100,000?  Depends.  1 in 100 is
     very bad.  Where do you draw the line?  Back-of-an envelope
     example of the effects:  NFS often transmits blocks of 6 Ethernet
     packets, the loss of any one of which results in the
     retransmission of all 6.  The loss of one packet in 12,000 means
     that every 2,000th block takes on the order of 2000 times longer
     to complete than normal, or performance is decreased to 50% of
     that on a working Ethernet.

     The Ethernet's packet loss problems are relative to those of your
     router, bridge, or switch.  Routers, bridges, and switches lose
     packets when their buffers fill up, so if your
     router/bridge/switch is losing one packet in 10,000, then for
     traffic passing through the router/bridge/switch, addressing an
     Ethernet packet loss rate of 1/100,000 would have little effect,
     and addressing an Ethernet packet loss rate of 1/10,000 would help
     no more than addressing your router/bridge/switch problem.

  25. Should I worry about Ethernet tailgating?

     Tailgating is a phenomena resulting from bugs in the design
     of Ethernet interfaces, which some vendors claim are due
     to ambiguities or changes in the Ethernet specification.  There
     was indeed a change in the IEEE 802.3 specification's wording
     designed to eliminate misunderstanding.

     Tailgating problems consist of packets following close after
     packets, collisions, and/or noise: so close that some network
     interfaces aren't ready to receive them yet.

     The standard says network interfaces should wait a minimum of
     9.6us after the end of a packet before sending another (the
     "interpacket gap").  Network interfaces typically don't start
     detecting the beginning of packets for a while after the end of a
     packet (i.e. carrier goes to idle) to avoid trying to treat the
     typical noise at the end of a packet as the beginning of the next
     packet.  This has been called its "blind time".  The standard
     doesn't specify how long the blind time should be, but naturally
     it must be less than the 9.6us interpacket gap.  However on real
     products, the blind times vary between a fraction of 1us and 4us
     or longer.

     Another element is that some network interfaces sometimes send 24
     bits of data while the line is idle: not a real packet:  somehow
     this causes short interpacket gaps.  My guess is that it makes
     some interfaces go blind while not stopping other interfaces
     from sending immediately.

     Some interfaces don't wait 9.6us after a collision before sending
     a packet.

     There have been interfaces that cheat on the 9.6us interpacket
     gap after a packet.  This is so explicitly against the standard
     that vendors of such products have been quick to fix them.
     Some products:

                                             Tailgate     Tailgate
                           Blind    24Bit    after        after
                           Time     Garbage  Collisions   Packets
                           -------  -------  ----------   --------
      IBM PCMCIA           0.6us
      (Notebook Sniffer)

      Intel 82596          4.6us              x
      (Desktop Sniffer)

      SEEQ 8003                      x        x
      (Cisco, oldSGI)

      AMD Lance AM7990     >4us
      (Sun)

      Intel 82586          long               x
      (oldSun)

      oldKalpana                                           x
                           -------   -------  ----------   --------
                                              Tailgate     Tailgate
                           Blind     24Bit    after        after
                           Time      Garbage  Collisions   Packets

     (Notes: Information from InfoWorld, 11/93 and 3/94; IBM PCMCIA
     cards are highly immune to the problems; Kalpana has fixed its
     switches)

     Example: If a network has two Suns that have Intel 82596 Ethernet
     chips (A and B) and two other stations (C and D), you can have the
     following situation:

       C and D send packets which collide.
       A sends a packet to B too soon after the collision.
       B remains blind too long to receive the packet.

     Thus TCP, NFS, or whatever, must retransmit.  Typical NFS
     retransmission time would be in the .5 to 1 second range, thus one
     lost packet translates into .5-1 second of waiting.  TCP
     retransmission time adjusts itself to the network & is typically
     shorter between stations on the same LAN, but, for example, can be
     long if the packet is lost between a station and a router while
     the station is talking over a WAN.

End of Memo: BIG-LAN Frequently Asked Questions